Directly call arithmetic primops instead of indirecting through builtins#66
Draft
gustavderdrache wants to merge 2 commits intomainfrom
Draft
Directly call arithmetic primops instead of indirecting through builtins#66gustavderdrache wants to merge 2 commits intomainfrom
gustavderdrache wants to merge 2 commits intomainfrom
Conversation
This gives a stack trace that is similar to calling the equivalent builtin. (That is, the first trace in an error will read either "while evaluating the %s operator" or "while calling the '%s' builtin".)
|
While we can probably all agree on the end goal and that going in this direction is desirable, it should be noted that this will cause existing code to silently evaluate differently than it did before. This may or may not lead to catastrophic circumstances on some end user's machine. For Lix, we instead chose the approach of forbidding the offensive overrides, which I'd recommend taking. This means that instead of silently changing semantics, code with operator overrides will now error out. (Feel free to take the commit, just make sure to also grab its fixup commit done a bit later which relaxes the rules for |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
Right now, some (but not all) of the Nix language's arithmetic expressions can be shadowed by overriding definitions:
As of this PR, this is no longer possible:
In addition, stack traces are annotated with "while evaluating the %s operator" for symmetry with the "while calling the '%s' builtin" from the current implementation:
Old:
New:
Context
This PR adds binary operation classes for the remaining builtins. As mentioned above, evaluation exceptions thrown have traces added for parity with the old reference to builtin calls. This somewhat inconsistent with other operators:
2 + (throw "bogus")does not mention the operator context. If this PR looks good, I can do a developer experience pass to get the error messages working.While I've factored out the arithmetic builtins, I haven't touched
prim_lessThanbecause of how it's handled withinprim_sort. I'd like to factor it out so that we can just directly use comparison operators instead of essentially backporting the old logic within the AST - maybe just use an enum to get a comparator.I haven't updated the tests. There are a few failures due to my having changed the error messages. I would like to see if this code is good before finalizing the error messages expected by the test suite.